The use of IP (internet protocol) to transport digital video is rapidly moving away from a simple, one-way UDP protocol. The emerging delivery methods do not use proprietary transports developed by content coding vendors (e.g. Adobe RTMP, available from Adobe Systems, Inc. of San Jose, Calif.) or other inefficient schemas that are based on progressive download or constant streaming of very large content files. The new methods embrace open standards and rely on transporting a series of small files (that when combined comprise the entire content asset) over an HTTP transport, or segmented HTTP transport (SHT). The SHTs typically use a construct called a manifest file to inform the client how to request the proper segments in the appropriate order. The small files are requested by the client devices and are being downloaded to the client buffer where they are assembled into a continuous flow, sent to the decoder and subsequently to the display for uninterrupted viewing. The buffer smoothes the play-out of often different sized segments asynchronously delivered over an IP network. One or more segments need to be delivered to the buffer before starting play-out.
Another feature that has been layered on top of SHTs that aids robustness of schema is called adaptive streaming. Rather than encoding content using single quality/bit rate setting for streaming or download, a method of simultaneous transcoding the single source content into multiple bit rates can be invoked. This process can create multiple versions of the same video at different resolutions and play-out bit rates that are time-equal and can be dynamically delivered to the same play-out device depending on the quality of its connection to the network. In this instance, the manifest file construct is extended with information that allows the client to play back at any of the encoded qualities.
The client can use a variety of algorithms to determine which play-out quality to choose. If operating conditions such as network congestion cause the client not to be able to receive the content at a previously requested resolution (e.g., bit rate) or if the CPU loading is too heavy and causing video frames to be dropped, then it may choose a lower quality version for the next segment(s) in the sequence. Conversely, if the conditions improve (connection quality or CPU loading), the client may ask for a higher quality version of the next segment.
Another augmentation of the adaptive SHTs is a feature called live streaming where the broadcasted programming is changed into point-to-point delivery in an almost real-time fashion. From a logical standpoint, the live streaming is not different than an on demand SHT, however from a real world standpoint at least two differences can be identified: 1) because the piece of content is being encoded in real-time, new segments are being created, so the manifest file is constantly updated, and 2) because the content is being produced and consumed at more or less the same time the client repeatedly requests an updated version of the manifest file to get information on how to request the newly added segments of video.
The migration to the HTTP transport brings about a number of benefits over proprietary or a UDP-based transport. HTTP is a standard that is broadly supported by network equipment like routers and CPE. Problems related to NAT (network address translation) that can occur with UDP-based transport protocol are not an issue with HTTP, which is based upon TCP. While there are multiple proprietary implementations of SHTs, as long as the SHTs are well behaved, the content segments can be cached in a traditional edge cache. The use of a content delivery network (CDN), which has globally distributed edge caches, provides a generic way to provide cost effective scale for content delivery.
However, the SHT content delivery method can sometimes cause problems with consistency of viewer's experience and perceived degradation of video quality. The issues result from the desire to quickly (faster than the actual play-back rate) pre-load the client's playback buffer with one or more segments to allow a new session to start. Also, when the viewer requests to fast-forward or rewind the content, the buffer is quickly re-loaded. If a fast re-load does not take place the playback will not start or resume, or after some time the client might request a switch the lower bit rate (and video quality) for the subsequent play-out.
In a bandwidth-constrained environment, especially access networks that carry multiple SHT flows, the frequent re-filling of play-out buffers and the resultant temporary increase of bandwidth by some client devices may have negative effect on performance of other client devices by consuming the available resources and causing ‘starvation’ of their buffers. As a result, many viewers can experience unexpected and annoying changes of video quality. To avoid such a video quality-flapping scenario, the service provider may choose to over-provision the bandwidth for each subscriber and incur higher delivery costs. In extreme cases, even generous bandwidth over-provisioning may not address the issues caused by SHT flows to devices with very deep buffers that play-out high definition content.
Bandwidth over-provisioning is inefficient and can impact a network operator's bottom line.
The current architecture of SHT solutions places most of the intelligence and responsibility for quality of play-out sessions inside the logic of client devices. The client decides what content play-out resolution to choose from the choices listed in the manifest file and makes requests for delivery of content segments (including fast pre-loading of the play-out buffer) without any consideration for other client devices that use the same network. All SHT client devices are inherently unaware of the state and needs of other devices.
Adaptive streaming has been designed to deliver the highest quality video from the client's perspective without considering the impact it can have on the delivery network.
SHT client devices can provide a sizeable memory buffer to their SHT players to better ‘ride’ over short duration network congestions, temporary delays associated with switching of routing of content segments and out-of-sequence delivery of the packets. The underlying HTTP protocols support retransmission of the corrupted or lost packets using the buffer as an elastic storage facility. Some implementations of the SHT players call for such buffers to be more than one minute deep, which translates into tens of Megabytes. The player has been designed to quickly fill-in at the start of the play-out session and re-fill when is emptied during the play-out. The buffer can be emptied whenever the viewer rewinds, fast-forwards the content, skips a commercial or makes a ‘jump’ to a different part of the content. Filling and re-filling of the buffers can cause significant increase of the demand for bandwidth that can affect other client devices that share the constrained network.
Like reference numbers and designations in the various drawings indicate like elements.